An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services. By way of example, an ESB typically performs the following:
Routing messages between services;
Converting transport protocols between requester and service;
Transforming message formats between requester and service; and
Handling business events from disparate sources.
An ESB system has two components. The first is a tooling component which enables a plurality of nodes to be wired together to form an overall message flow. The message flow conceptually describes the particular function of an ESB module being defined. For example a flow may be defined to model a situation in which messages are first received (by a receiving node), then transformed to a different format (by a transformation node), logged (by a logging node) and sent (by a sending node) to a message consumer.
The second component is a flow builder which uses the conceptual representation defined by a modelled message flow to create runtime artefacts and to order these appropriately. In order to instantiate a runtime artefact (node) into a message flow, the flow builder accesses code representing the node. The flow builder has access to a library of code representing various nodes that may be required for wiring into a message flow and selects from this library according to the underlying model.
Each runtime artefact is populated by the flow builder with parameter options specified by the model. For example, a logging artefact may take the properties “enabled” and “location” to define whether logging is enabled and where a message should be logged to. The enabled property (parameter) may take either “on” or “off” values and the location property takes one of a number of possible logging locations.
One example of such a system is the pairing of IBM's WebSphere® Integration Developer, which provides the ESB tooling support, and IBM's WebSphere® Enterprise Service Bus, which provides the runtime environment.
Such a system may be used to create a flow which requires similar function, represented by the same sequence and type of nodes in a flow, but with numerous routes using different configurations of some of the nodes in the flow. This requires a flow with filtering and branching logic to direct the flow to one of several hardwired flows each with a different variant of the configuration.
This situation is described with reference to FIGS. 1a and 1b. A filter node 10 receives a message (step 20). Filter node 10 is programmed to determine (in this example) whether logging of the message is required and to route the message to the appropriate node (A, B, C) in order to log the message to a suitable location. Thus at step 30 the filter node 10 examines the logging properties in the message. Such properties may be an “enabled” property (which specifies whether logging is on or off) and a “location” property (which specifies where a message should be logged to). Based on the information provided in the message an appropriate node is selected in order to actually do the logging (step 40). Thus if logging is set to on and database Y is specified as the location to which to log, node B is selected. Node B then performs the appropriate processing. Once the message has been directed towards the appropriate node, the message then continues along the appropriate message flow (e.g. B, B2, B3).
It should be appreciated that each of nodes A, B and C are the same type of node and perform the same sort of functionality. Each one is, however, slightly different than its peers because it requires a different configuration. In order to achieve the level of function required, the filter node will have to make a decision on the context of the flow, by examining the incoming message, and route based on that contextual information to the most appropriate node.
Thus it is possible to create the equivalent to a case statement in the C or Java programming language using messaging flows. The filter node provides the ‘switch’ logic and the subsequent nodes cater for the various combinations (cases).
This is a static programming model and results in some difficulties. The flow representation can be complex. Further if a new ‘case’ is required, then a new node (node D) would have to be configured and the switch (filter) logic would need updating to take account of new node. Configuring a node can be time consuming and costly. Typically, development of an industrial application will take place over an extended period, involving a number of roles. In this example, a Solution Designer would have to inform an Integration Developer of the additional case, runtime artefacts would have to be created or modified and passed to a System Administrator to install and test in the systems environment. In many cases the Integration Development may be done by a third party, with a more obvious cost impact.